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[57] ABSTRACT 

An Internet/intranet-based arrangement for interaction 
between a messaging system and a message originator and 
delivery of the message originator's message to a mailbox of 
the messaging system uses TCP/IP communications appli- 
cations such as HTTP, Telnet, FTP, or Chat as information- 
transfer and message delivery mechanisms, creating an 
Internet/intranet-based text, binary, video, and/or multime- 
dia file message-delivery analogue to the call-answer 
message -creation capability of telephony-based messaging 
systems. 
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INTERNET/INTRANET USER INTERR^CE 
TO A MULTIMEDIA MESSAGING SYSTEM 

TECHNICAL FIELD 

This invention relates to electronic messaging. 

BACKGROUND OF THE INVENTION 

Voice messaging systems have long provided the service 
of accepting and recording voice messages for subscribers 
from impromptu callers. In these systems, message origina- 
tion is not restricted to subscribers of these messaging 
systems or to subscribers of remote messaging systems that 
are networked with these systems; rather, any caller can 
originate a message. As voice messaging and e-mail systems 
become integrated into multimedia messaging systems, it 
becomes desirable to extend the call -answer capability of 
voice messaging systems to text messages and other 
message-media besides voice, and to make this capability 
available to substantially any and all possible message 
originators, without pre-subscription and without preference 
or deference to the computer operating system of the origi- 
nator. 

One promising opportunity is to use platform- 
independent TCP/IP (transmission control protocol/Internet 
protocol) applications or platform-independent Web brows- 
ers and the growing community of TCPAP and Web users to 
provide the connectivity infrastructure that is needed to 
deliver new types of electronic media directly into the 
mailboxes of a multimedia messaging system. The TCP/IP is 
the standard protocol suite of the Internet. Because of the 
Internet's popularity, TCP/IP applications have been written 
and are being distributed for essentially all major computer 
operating systems. Of specific interest are the FTP (file 
transfer protocol) protocol which allows the simple transfer 
of files between computers. Telnet which supports terminal 
emulation and login to host capabilities, and Chat which is 
a simple spht-screen two-way text interface application that 
allows two people to type to each other simultaneously. 
Similarly, Web services on the Internet are being marketed 
and supported as a non-subscriber-based global information- 
distribution mechanism. Because of its popularity, Web 
browser applications have been written and are being dis- 
tributed for essentially all major computer operating sys- 
tems. These TCP/IP applications and Web browsers there- 
fore provide a widespread infrastructure for text, binary, and 
other media message delivery. 

Conventional Web integrations with mailboxes focus on 
retrieval of messages, where the mailbox is owned and the 
messages are retrieved by the message recipient who typi- 
cally already has a mailbox user- interface application which 
has capabilities preferable to those provided by a Web 
browser. But such integrations do not benefit a message 
originalor who has the abifity to send full multimedia 
messages and who is not a subscriber to the messaging 
system. Some existing Web browser applications do include 
the ability to send e-mail. But this is done via the standard 
e-mail SMTP protocol which inherently has the disadvan- 
tages of requiring an aflBliation with an SMTP server to 
fulfill the e-mail dehvery request. Such an afiSliation is not 
usually available without pre-subscription. The SMTP pro- 
tocol also does not assure confirmed delivery into the 
recipient*s mailbox. 

SUMMARY OF THE INVENTION 

Illustratively according to the invention, technical 
advance over the art is achieved by a method of and an 
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apparatus for interaction between a messaging system and a 
message originator, and delivery of the message originator's 
message to a mailbox of the messaging system, over an 
Internet and/or an intranet (refenred to herein as Internet/ 

5 intranet for short) by using TCP/IP communications apph- 
cations such as HTTP, Telnet, FTP, or Chat as information- 
transfer and message-delivery mechanisms. This effectively 
creates an Intemet/intranel-based text, binary, video, and/or 
multimedia file message -delivery analogue to the call- 
answer message-creation capability of telephony-based 
messaging systems. This arrangement improves multimedia 
message delivery into mailboxes for those who do not have 
access to gateways which deUver messages into the mes- 
saging system. It allows message contents to be delivered 
without regard for the application, the messaging infrastruc- 

15 ture platform, or the operating system. Message delivery is 
advantageously immediate and confirmed, and the message 
cannot be delayed or lost in a gateway or a store-and- 
forward post office. 
Generally according to the invention, messaging in a 

20 communications system that comprises a user terminal and 
a messaging system interconnected by an Interaet/intranel is 
effected in the following manner. A request identifying a 
subscriber of the messaging system is sent from the user 
terminal via the Internet/intranet to the messaging system. In 

25 response to receipt of the request at the messaging system, 
subscriber information corresponding to the identified sub- 
scriber is sent fi-om the messaging system via the Internet/ 
intranet to the terminal. In response to receipt of the sent 
subscriber information at the terminal, the sent subscriber 

30 information is presented to a user of the terminal. In 
response to the user providing message information at the 
terminal, the message information is sent from the terminal 
via the Internet/intranet to the messaging system. In 
response to receipt of the sent information at the messaging 

35 system, the message information is composed (e.g., 
formatted) into a message of the messaging system, and the 
message is stored in the messaging system in a mailbox of 
the identified subscriber. Messaging effected in this manner 
gives the Internet/intranet user — any user, irrespective of 

40 whether they are or are not a subscriber of the messaging 
system — an interaction and message-delivery analogue to 
the call-answer message-creation scheme of telephony- 
based messaging systems. This is particularly true when the 
subscriber information sent to the terminal and played to the 

45 user includes the subscriber's presently-active personal 
greeting. Preferably, the sending of information via the 
Internet/intranet is effected by using at least one of the 
following protocols: HTTP, FTP, Telnet, and Chat. By using 
these standard and widely-available TCP/IP communica- 

50 tions mechanisms, the effected messaging is made instantly 
and widely accessible without change to the existing 
Internet/intranet infrastructure. 

Also preferably, in response to the storing of the message 
in the messaging system, an acknowledgment thereof is sent 

55 from the messaging system via the Internet/intranet to the 
terminal and presented there to the user. Message delivery is 
thus advantageously immediately confirmed to the message 
sender. Further preferably, the subscriber information sent to 
the terminal includes a form — a Web page, for example — for 

60 filling out by the user with the message information, and 
sending of the message information is performed in response 
to the user filling out the form with the message information. 
The user can therefore concentrate on composing the mes- 
sage content without having to worry about the format of the 

65 message and about whether or not he or she has remembered 
to select or specify any or all variable aspects of the 
message. 
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These and other advantages and features of the present tion to Internet/intranet 1Q2, system 101 includes an HTTP 

invention will become more apparent from the following server daemon process 206. A daemon is a server process 

description of an Ulustrative embodiment of the invention that runs in the background, waiting for a service request to 

considered together with the drawing. be made by an appHcation, and thereafter effects the service. 

5 As a part of effecting the service, the daemon may function 

BRIEF DESCRIPTION OF THE DRAWING as a client of another server. In this illustrative exainple, 

daemon process 206 is implemented as a conventional 

FIG. 1 is a block diagram of a communications system HTTP server program, such as a Netscape Communications 

which implements an illustrative embodiment of the invcn- Server or an NCSA HTTP Server, modified lo implement 

tion; jQ special processing of the meta-character embedded 

FIG. 2 is a block diagram of a first illustrative implemen- within a URL (as described below) to invoke processing of 

tatioD of the multimedia messaging system of FIG. 1; a Common Gateway Interface (CGI) script 207. Process 206 

FIG. 3 is a block diagram of a second illustrative imple- ^ interfaced to the data stmctures and to other processes of 

mentation of the multimedia messaging system of FIG. 1; system 101 by an application program interface (API) which 

. , c 1 fl J- f ft i< comprises an API client hbrary 204 and an API service 

HGS. 4-6 are a ftmctional flow diagram of hinctions 15 ^^^^^^ ^^^^^^^ .J^^ 

performed by e ements f muM ^^^^^^ ^ 205 in other cases. In the case 

and the terminal of FIG. 1 to effect an In^rnet/in ranet-b^ed ^^^^^ system, API 204, 208 

call-answer-like message delivery capabdity within the sys- ^ ^^^^^ Messaging API (IMAPI). 

tem of FIG. 1; and . , , • r4>. ^ . u 

. „, ^ ^ 90 Alternatively, as shown m FIG. 3, system 101 may have 

FIG. 7 is an lUustration of a subscriber Web home page ^^^^^^^ ^^h it a separate computer 301 which imple- 

lemplate of the multimedia messaging system of FIG. 1. ^^^^ ^^^^ ^^^^^^ ^^^^^ 206 and the send-it 

TAT?T-AiT rMTooDiiynrLM process 205 and acts as an Internet/intranet 102 server on 

DETAILED DESCRIFJION f ■ ir c . ath v ^ i u 'jha -a 

behaff of system 101. API chent hbrary 204 resides on 

RG. 1 shows a communications system which embodies 25 computer 301, while API service daemon 288 resides on 

an illustrative implementation of the invention. It comprises system 101. Elements 204 and 208 communicate with each 

a multimedia messaging system 101, such as the Lucent other via a conventional TCP/IP socket mechanism 300. 

Intuity® messaging system, which is connected by voice FIGS. 4-6 show the functions performed by multimedia 

ports to a telephone system 100 and by a data LAN con- messaging system 101 and entities associated with system 

nection to an intranet and/or an Internet 102. Also connected 30 101 in cooperation with browser 104 of terminal 103 to 

to Internet/intranet 102 is at least one terminal 103, such as provide a user of terminal 103 with a functionally-similar 

a personal computer (PC), equipped with a Web browser user interface to system 101 as system 101 provides to 

104, such as a Netscape Navigator or a Microsoft Internet telephone callers. When the user of terminal 103 wishes to 

Explorer. send a message via system 101, the user sends out a request 

Conventionally, a user of terminal 103 communicates 35 via browser 104 over IntemetAntranet 102 to location 

over Internet/intranet 102 with other terminals and with "http://<:server address>/~<extension>" or to location 

servers (not shown). If the user is a subscriber of messaging "http://<server address>/~<name>", at step 400, where 

system 101, the user can also communicate with multimedia <server address>is the Internet/intranet domain name of 

system 102 via terminal 103 equipped, for example, with a HTTP server daemon process 206, and <extension> or 

Lucent Technologies Inc. Intuity® Message Manager, to 4.0 <name> is the telephone number or surname of the intended 

retrieve messages stored therein for the user. Also message recipient. The sent-out request also includes the 

conventionally, users of telephone system 100 communicate remrn Internet/intranet address (e.g., IP address and socket 

via telephones (not shown) with multimedia messaging identification of the reqtiesting browser) of requesting ter- 

system 101 to deposit messages in and to retrieve messages minal 103. Daemon process 206 receives the request (a 

from mailboxes of system 101. Typically, when a caller is 45 URL), at step 402, detects the meta-character and in 

connected to system 101, system 101 answers the call and response it logs into system 101 through API 204, 208, at 

plays to the caller a greeting — either a system greeting or a step 404, either as a special, mailbox-less, type of subscriber 

personal greeting of the called subscriber — followed by a or as a conventional subscriber who is the owner of "Web 

menu of choices that arc available to the caller, including the Call Answer** mailbox 202. Conventional processes of sys- 

choice to record a voice message for the subscriber and store 50 tem 101 accept the login, at step 406, and daemon process 

it in the subscriber's mailbox. 206 forwards the received request through API 204, 208 to 

According to the invention, multimedia messaging system system 101, at step 408, as a directory lookup request to find 

101 provides a fiinctionaUy-similar user interface to a user the subscriber ID that corresponds to the received name or 

of terminal 103 who accesses system 101 via Intemet/ telephone extension. Conventional processes of system 101 

intranet 102 as it provides to a telephone caller who accesses 55 receive the request, at step 410, and search subscriber 

system 101 via telephone system 100. System 101 is a directory 203 for the desired record, at step 412. If system 

stored-program-comroUed processor system that includes 101 does not find a subscriber ID corresponding to the 

various data stmctures and processes. As shown in FIG. 2, received name or extension, as determined at step 414, it 

the data structures include conventional subscriber mail- remrns a "no match" indication via API 204, 208 to daemon 

boxes 200-201 for storing of multimedia messages, and a 60 process 206, at step 416. Id response to receipt of the "no 

subscriber directory 203 which stores records of inforaiation match" indication, at step 418, daemon process 206 logs out 

about subscribers of system 101 that may include their of system 101, at step 420, and forwards ibe "no match" 

names, telephone numbers, subscriber IDs, personal message via Internet/intranet 102 to terminal 103, at step 

greetings, call coverage paths, alternate contact numbers, 422. At terminal 103, browser 104 receives the message and 

personal calendars, personal photographs, etc. The data 65 displays it to the user, at step 424. 

structures may also include a dummy mailbox 202 for a Returning to step 414, if a record matching the request is 

generic phantom "Web call answer" subscriber. For connec- found, system 101 checks if it is a unique match, at step 430. 
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The match will be a unique match for a telephone extension, 
but may not be a unique match for a name. If the match is 
not unique, system 101 returns the subscriber names of all 
matching records, and a prompt to select one of them, via 
API 204, 208 to daemon process 206, at step 432. Upon 
receiving the matching names and prompt, at step 434, 
daemon process 206 forwards them along with a return 
Internet/intranet address of daemon process 206 via Internet/ 
intranet 102 to the return address of terminal 103, at step 
436. Browser 104 receives the matching names and prompt 
and displays them to the user, at step 438. When the tiser 
makes a selection of one of the names, browser 104 returns 
an indication of the selection to daemon process 206 via 
Internet/intranet 102, at step 440. Upon receiving the 
selection, at step 442, daemon process 206 forwards it via 
API 204, 208 to the return address of daemon process 206 
at system 101, at step 444. Upon receipt of the selection, at 
step 446, or if a unique match had been found at step 430, 
conventional processes of system 101 return the subscriber 
ID of the selected matching subscriber to daemon process 
206 via API 204, 208, at step 448. 

Turning now to FIG. 5, daemon process 206 receives the 
subscriber ID, at step 500, and in response requests the 
subscriber record for that subscriber ID from system 101, at 
step 502. Conventional processes of system 101 respond to 
receipt of the request, at step 504, by retrieving and returning 
the requested record, at step 506. Upon receipt of the record, 
at step 508, daemon process 206 logs out of system 101, at 
step 510, and then proceeds to dynamically generate a Web 
home page for the subscriber from the received record, at 
step 512. Illustratively, daemon process 206 creates the 
subscriber's home page by populating fields 701 of a generic 
Web home page template 700 (i.e., a form) with the sub- 
scriber's information, including the subscri*ber ID, from the 
received record. An example of such a generic Web home 
page template 700 is shown in FIG. 7. Alternatively, sub- 
scribers of messaging system 101 may be allowed to create 
and store, linked to their records in subscriber directory 203, 
their own custom Web home pages that are functionally 
equivalent to a populated page template 700, in which case 
daemon process 206 merely retrieves the identified subscrib- 
er's custom home page at steps 502-512. Daemon process 
206 then uses the TCP/IP protocol to send the subscriber's 
home page over Internet/intranet 102 to the return address of 
terminal 103 which had sent the original request at step 400, 
at step 514, and then discards the subscriber's home page, at 
step 516. If and when it receives another request for that 
subscriber, daemon process 206 will again retrieve the 
subscriber's record and create the home page anew, thus 
ensuring that any changes that might have been made to the 
subscriber's record (e.g., a new active personal greeting) 
will be reflected in the newly-requested home page. 

The subscriber's home page that was sent by system 101 
at step 514 is received by browser 104 and is displayed to the 
user on the display of terminal 103, at step 520. If any of the 
fields of the home page (e.g., "Today's greeting") include 
audio information, displaying of the home page on terminal 
103 may include an HTML anchor including the meta- 
character for playback of the audio information to the user. 
When the user selects the anchor, the audio information is 
provided by the server via the meta-character processing 
as described. To send a message back to the subscriber, the 
user fills out the message fields 702 of the displayed home 
page, at step 522. Typically, the fields filled out by the user 
are at least a header field 703 that indicates who the message 
is from, the subject of the message, the user's return address 
etc., and a message-body text field 704, as shown in FIG. 7. 
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When the user is done entering the message, he or she 
invokes a message -send function, illustratively by pointing 
to and clicking on a "SEND MESSAGE" virtual button 705 
of the displayed home page, at step 524. The "SEND 
MESSAGE" button 705 is coded with the URL of a CGI 
script 207 which invokes the send-it process 205 of system 
101. In response, browser 104 sends data files of the 
message fields 702 filled out by the user, the subscriber ID 
of the intended message recipient, and the return address of 

10 terminal 103, as a message to the URL of send-it process 205 
at system 101 via Internet/intranet 102, at step 526. 

Turning to FIG. 6, HTTP server daemon process 206 
receives the message files at system 101, at step 600, and in 
response to the URL of send-it process 205 invokes send-it 

15 process 205 of system 101, at step 602. Upon invocation of 
send-it process 205, at step 604, daemon process 206 
forwards the message files and the subscriber ID of the 
subscriber who is to receive the message, at step 606. Upon 
receipt of the message files and subscriber ID from daemon 

20 process 206, at step 608, send-it process 205 uses the 
received information to compose a message in the conven- 
tional format of system 101, at step 610. Send-it process 205 
then logs into system 101, at step 612, and when system 101 
accepts the login, at step 614, send-it process 205 delivers 

25 the message to system 101 addressed to the recipient sub- 
scriber's ID, at step 616. System 101 accepts the message, 
at step 618, and delivers it to mailbox 200 of the recipient 
subscriber, at step 620. System 101 then returns an acknowl- 
edgment of successful message delivery to send-it process 

30 205, at step 622. In response to receipt of the 
acknowledgment, at step 624, send-it process 205 logs ofif of 
system 101, at step 626, and system 101 accepts and 
completes the log off, at step 628. Send-it process 205 then 
deletes the message files that it had received at step 608, at 

35 step 628, creates an acknowledgment message indicative of 
successful delivery of the message and addressed to the 
return address of terminal 103, at step 630, and forwards the 
acknowledgment message to daemon process 206, at step 
632. Daemon process 206 responds to receipt of the 

40 acknowledgment message, at step 634, by sending a Web 
page containing the message via the TCP/IP protocol over 
Internet/intranet to terminal 103, at step 636. Ternainal 103 
receives the Web page and browser 104 displays it to the 
user/message sender on the display of terminal 103, at step 

45 638. The acknowledgment message created at step 630 may 
be a negative acknowledgment, e.g., "This mailbox is full. 
Message unable to be delivered." The message sender is thus 
given substantially immediate confirmation of the dehvery 
or non -delivery of his or her message. 

50 Of course, various changes and modifications to the 
illustrative embodiment described above will be apparent to 
those skilled in the art. For example, protocols other than the 
Web may be employed to effect the same type of service. Of 
specific interest are the FTP protocol, which allows the 

55 simple transfer of files between computers, Tebet, which 
supports terminal emulation and login to host capabilities, 
and Chat, which is a very simple split-screen two-way 
typing application allowing two people to type at each other 
simultaneously. This provides the requisite infrastructure for 

60 text and binary file message delivery. An illustrative imple- 
mentation for each of these protocols is outlined by the 
following steps: 
For FTP: 

L Set up an FTP server with a directory for each extension 
65 having a corresponding enabled mailbox. Symbolically link 
a directory of the extension's corresponding username to the 
extension directory, to enable addressing of the extension 
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directory by name. Allow changes in directory to find 
"enabled" mailboxes by naming the directories with the 
subscriber's name and/or telephone number/extension. 

2. Put up a "read_me_first" file for visitors to the 
mailbox. This file contains the mailbox owner's name, the 5 
Active Greeting Annotation, and any other visual informa- 
tion that the subscriber wishes to display, and includes 
information about downloading the audio greeting in an 
appropriate voice' format, and uploading files into the mail- 
box. (See below), 

3. Use a daemon process to monitor the greeting infor- 
mation associated with a mailbox to extract information 
from the messaging system through an API and re-generate 
the appropriate "read_me_„first'* and greeting files in each 
directory. This daemon process is also responsible for mooi- 15 
toring the subscriber's FTP directory for new files, and 
efitectualing delivery of uploaded files to the associated 
mailbox in the messaging system. 

4. The daemon process uses the FTP login information as 
the originator information when delivering the file. 20 

5. The message subject is the name of the delivered file. 

6. A standard FTP copy operation allows the upload of 
multimedia files. Muhimedia types and formats are indi- 
cated by conventional filename extensions, for example, 
.WAV, .TIF, .BMP, or .TXT. 25 

7. The message is delivered using default delivery 
options, such as not-private, not-priority, etc. 

8. It may be desirable to limit the size and number of files 
that an Internet caller may place in the mailbox during a 
single FTP session similarly to the way that telephone 30 
answering limits the caller to a single message per call, to 
ensure that a single session cannot seize all available mail- 
box space. 
For Telnet: 

1. Set up a Telnet server and set up a restricted login for 35 
visitors to the messaging system. The restricted login is set 
to accept a recipient's mailbox address by name or telephone 
number/extension, collect the caller's name and authentica- 
tion handle (if offered), subject, and delivery options, and 
then execute a user-selected editor once and then drop the 40 
session, 

2. On successful login, a text greeting is generated and 
displayed. The greeting information associated with a mail- 
box is extracted from the messaging system through a 
messaging API. The displayed greeting contains the mailbox 45 
owner's name, the Active Greeting Annotation, and any 
other visual information that the subscriber wishes to dis- 
play. 

3. The Telnet editor session is used to generate a text 
message. Operations on the Tehiet cUent, such as cut and 50 
paste, are allowed. 

4. When the editing session is complete, the contents of 
the edit buffer are delivered as a message. 

5. 11 may be desirable to hmit the size of the edit buffer 
in a Tehiet session similarly to the way that telephone 55 
answer limits the caller to a single message per call, to 
ensure that a single session cannot seize all available mail- 
box space. 
For Chat: 

1. Set up a Chat server conforming to the Talk protocol for 60 
visitors to the messaging system. 

2. Set up a daemon process to terminate the Talk protocol 
on behalf of enabled mailboxes. The user may be specified 
by mailbox address, by name, or by telephone number/ 
extension. ^5 

3. On successful connection, a text greeting is generated 
and displayed. The greeting information associated with a 



mailbox is exu-acted from the messaging system throiigh a 
messaging API. The displayed greeting contains the mailbox 
owner's name, the Active Greeting Annotation, and any 
other visual iriormation that the subscriber wishes to dis- 
play. 

4. A series of two or more outbound messages prompts the 
caller to enter their name and authentication handle (if 
offered), and subject. The next two messages received are 
used on message delivery to populate these messaging 
fields. 

5. The remainder of what is typed by the caller is captured 
and saved as text. 

6. When the session is complete, the contents of the 
captured text are delivered as a message. 

7. It may be desirable to limit the duration and size of the 
text-capturing function in a Chat session similarly to the way 
that telephone answering limits the caller to a single mes- 
sage per call, to ensure that a single session cannot seize all 
available mailbox space. 

In all of the cases above, if the layout of the Web greeting 
page is done in standard HTML description format, then the 
FTP "read_me_first" file, the Chat outbound message, and 
the Tehiet login message are jiist text-only renderings of this 

page. . . r 

Also, automatic capture of authentication information 
from Internet callers when they access the service may be 
included. For example, the IP address and server name of the 
originating terminal 103 may be identified in the "From:" 
field of the message. Or, subscribers of the messaging 
system may be allowed to create their own custom HTML 
greeting documents and install them on the messaging 
system as one of their valid personal greetings. Such greet- 
ings may include interactive capabilities, e.g., "Press one to 
get a map to my office; press two to automatically schedule 
a meeting with me.", etc. Such forms of greeting or call- 
handling can be represented as Web templates, described 
above. Such changes and modifications can be made without 
departing from the spirit and the scope of the invention and 
without diminishing its attendant advantages. It is therefore 
intended that such changes and modifications be covered by 
the following claims. 
What is claimed is: 

1, A method of messaging in a communications system 
comprising a user terminal and a messaging system inter- 
connected by an Internet/intranet, comprising the steps of: 

sending a request identifying a subscriber of the messag- 
ing system from the user terminal via the Internet/ 
intranet to the messaging system; 
in response to receipt of the request at the messaging 
system, sending subscriber information corresponding 
to the identified subscriber from the messaging system 
via the Internet/intranet to the terminal; 
in response to receipt of the sent subscriber information at 
the terminal, presenting the sent subscriber information 
to a user of the terminal; 
in response to the user providing message information at 
the terminal, sending the message information from the 
terminal via the Internet/intranet to the messaging 
system; 

in response to receipt of the sent message information at 
the messaging system, composing the message infor- 
mation into a message of the messaging system; and 
storing the message in the messaging system in a mailbox 
of the identified subscriber. 

2. The method of claim 1 further comprising the steps of: 
in response to the storing, sending an acknowledgment of 

the message from the messaging system via the 
Internet/intranet to the terminal; and 



07/25/2003, EAST Version: 1.04.0000 



6,038,296 



10 



10 



in response lo receipt of the acknowledgment at the 
terminal, presenting the acknowledgment to the user. 

3. The method of claim 1 wherein: 
each sending of information via the Intcmct/intranct is 

effected by using at least one of the following proto- 
cols: HTTP, FTP, Telnet, and Chat. 

4. The method of claim 1 wherein: 
the subscriber information sent to the terminal includes a 

personal greeting of the subscriber. 

5. The method of claim 1 wherein: 
the subscriber information sent to the terminal includes a 

form for filling out by the user with the message 
information; and 
the step of sending the message information is performed 15 
in response to the user filling out the form with the 
message information. 

6. An apparatus for performing the method of claim 1 or 
2 or 3 or 4 or 5. - 

7. A method of messaging in a communications system 20 
comprising a user terminal that includes a Web browser and 

a multimedia messaging system, both interfaced to and 
interconnected by an Internet/intranet, comprising the steps 
of: 

in response to a prompt from a user of the terminal, the 25 
Web browser sending firom the terminal a request 
addressed to an Internet/intranet address of the mes- 
saging system and identifying by at least one of name 
and telephone number a subscriber of the messaging 
system, and including an Internet/intranet address of 30 
the terminal; 

In response to receipt of the request at the messaging 
system, determining a subscriber identifier of the sub- 
scriber within the messaging system; 

in response to a determination of the subscriber identifier, 
retrieving stored subscriber information associated 
with the subscriber identifier from the messaging sys- 
tem; 

in response to the retrieval, composing a Web home page 
for the subscriber from the retrieved subscriber 
information, the Web home page including a return 
address of the messaging system, the subscriber iden- 
tifier of the subscriber, and space for message infor- 
mation from the user; 



35 



40 



in response to the composing, sending the subscriber's 
Web page addressed to the Internet/intranet address of 
the terminal; 

in response to receipt of the subsCTibcr's Web page at the 
terminal, the Web browser presenting the subscriber's 
Web page to the user; 

in response to receiving message information firom the 
user in said space in the Web page and a prompt from 
the tiser, the Web browser sending from the terminal the 
message information, subscriber identifier of the 
subscriber, and the Internet/intranet address of the 
terminal, addressed to the return address of the mes- 
saging system; 

in response to receipt of the message information at the 
messaging system, formatting the messaging informa- 
tion into a message of the messaging systenii; and 

in response to receipt of the subscriber identifier of the 
subscriber at the messaging system, storing the mes- 
sage in a mailbox of the subscriber in the messaging 
system. 

8. The method of claim 7 further comprising the steps of: 
in response to the storing, sending an acknowledgment 

thereof from the messaging system addressed to the 
address of the terminal; and 
in response to receipt of the acknowledgment at the 
terminal, the Web browser presenting the acknowledg- 
ment to the user. 

9. The method of claim 7 further comprising the step of: 
after sending the subscriber's Web page, deleting the 

subscriber's Web page from the messaging system, so 
that receipt of another request at the messaging system 
identifying same said subscriber will result in compos- 
ing anew a Web home page for the subscriber, whereby 
changes made to the stored subscriber information 
inbetween the receipt of the requests is reflected in the 
Web home page that is composed anew. 

10. The method of claim 7 wherein: 

each sending via the Internet/intranet is effected by using 
an HTTP protocol. 

11. An apparatus for perfonning the method of claim 7 or 
8 or 9 or 10. 
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